The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Client-server computer systems are commonly used to provide electronic transaction processing services over public data networks. In these systems, a large number of client systems, which are distributed across one or more networks, are serviced by a server site. Because each client system normally requires server resources for only a short time, one server site can often service hundreds, thousands or even millions of clients.
For example, online electronic commerce is supported, in part, by transaction processing systems that interact with numerous distributed merchant systems. When a customer contacts a merchant to perform an electronic commerce transaction, the customer may provide a credit card number for payment of goods or services. The merchant establishes a connection to a transaction processor, and sends a request message containing customer identification information, a credit card number, an order amount, and other information; thus, the merchant requests the transaction processor to authorize the credit card for the specified amount. The transaction processor contacts a payment processor to request a reservation of credit equal to the specified amount, etc. In response, the transaction processor receives an authorization code and associates it with the credit card number, amount, merchant identifier, and other information representing a state of the credit card transaction.
Later, the merchant may wish to capture an amount of value equal to the purchase amount. Accordingly, the merchant may request the transaction processor to perform a billing operation in which the customer is charged for the specified amount. In the billing request, the authorization code is referenced. In response, the transaction processor must locate all other information relating to the transaction, based on the authorization code, so that a billing operation can be performed.
In this context, and in other client-server contexts, there is a need to store a large volume of information representing the state of numerous transactions. In the electronic commerce transaction example given above, the transaction processor and the merchant may communicate with a communication protocol using computing elements that do not inherently store state information; that is, the protocol is “stateless.” Examples of stateless protocols include HTTP. In this environment, normally the transaction processor creates and stores a transaction record on one of its servers in response to receiving an initial message from the merchant for a particular transaction. The transaction record contains a transaction identifier, information about the parties to the transaction, the nature of the transaction, etc. If the transaction processor is servicing a large number of merchants who have a large number of customers, over time, vast volumes of state information must be maintained.
In one approach, the state information is stored on the server side, for example, in data storage equipment that is accessible to the transaction processor. However, this approach requires large amounts of data storage equipment, driving up costs for the transaction processor. There may be millions of state records stored on dozens or hundreds of disk storage units, for example. If transaction volume fluctuates widely, which can occur during seasonal sales cycles, periodically the transaction processor may have far too little or far too much storage capacity.
Further, this approach is non-scalable, because the amount of required data storage equipment tends to increase approximately linearly with transaction volume. In addition, the data storage equipment and the data require management, increasing personnel costs for the transaction processor.
Still another disadvantage of this approach is that the majority of the data is not needed, or discarded, after a relatively short time. For example, in credit card transaction processing, in one system approximately 70% of all credit card authorizations result in a billing operation within the same day. While the authorization codes are typically valid for seven days, the state information is essentially needed only for a short period, but storing it for that period has a high cost.
Another problem of this approach is that if storage of the state information is spread across multiple machines, significant overhead is introduced when a particular authorization code is searched. Therefore, typical front-send servers of transaction processors have extremely high capacity and other performance characteristics, and are expensive.
Another approach is to require each client to store all its own state information. Since the client provided the original transaction information and receives other state information back from the server, such as the authorization code in the credit card example given above, the client has all pertinent state information available to it for storage. However, this approach has significant drawbacks. First, in many contexts it would require a major change in the way clients do business, require reprogramming their systems, and require capital investment in data storage systems. Second, in the context of e-commerce transaction processing, many merchants do not wish to store credit card numbers for liability and risk containment reasons.
Thus, there is a need for a way to store large volumes of state information for electronic transactions, without requiring server-side storage of the information.
It would be especially useful to have a way to maintain large volumes of state information without large amounts of data storage equipment.
Steganography is a technique of hiding a secret message in another message, such that the very existence of the secret message is concealed. In one approach, the sender writes an innocuous message and then conceals a secret message on the same piece of paper. Historical variants include invisible inks, tiny pin punctures on selected characters, minute differences between handwritten characters, pencil marks on typewritten characters, grilles that cover most of the message except for a few characters, and others.
More recently, steganography has been used to conceal an electronic message in a graphical image. For example, the least significant bit of each byte of a graphic image may be modified such that extracting and assembling all such least significant bits provides the message. The visual appearance of the graphical image does not change appreciably, because most graphics standards specify more gradations of color than the human eye can notice. Using this technique, a 64-kilobyte message can be concealed in a 1024×1024-bit gray-scale image. Another recently developed steganographic technique involves the use of obfuscation functions or “mimic functions.” Such functions modify a message so that its statistical profile resembles that of something else that does not appear to comprise an encoded message.